DataServer and WebSpeed architecture
You have the option of having a local or a remote DataServer. A local DataServer runs on the same machine as the WebSpeed agents. A remote DataServer runs on a different machine from the WebSpeed agents.
Figure 12–1 shows a DataServer that is local to the WebSpeed Transaction Server. The database also resides on this machine. (However, the database does not have to be local.)
Figure 12–2 shows one possible configuration for the remote DataServer where a WebSpeed agent accesses a remote DataServer. Here, the database and the DataServer are running on the same machine. The schema holder is local to the WebSpeed Transaction Server to increase performance.
The figures show a schema holder on the same machine where your agents run. A local read-only schema holder gives you better performance. However, you might decide that you want your schema holder on a separate machine to make better use of processing resources.
Note that none of the configuration diagrams include a Web server. The Web server plays no role after passing the initial Web request for data to the WebSpeed Messenger. Much like a typical OpenEdge client, the WebSpeed agent interacts with the DataServer, which in turn passes queries and data requests to the database management system.
You can integrate DataServers for ODBC and ORACLE into the Progress Explorer administrative framework, which allows you to have a single administrative system and take advantage of the NameServer’s load balancing. Alternately, the WebSpeed agents can access DataServers that cannot be managed by the AdminServer.
There are variations on these configurations that allow you to combine Windows and UNIX platforms or to distribute the components using vendor networking (for example, ORACLE’s SQL*Net). See your OpenEdge DataServer guide for more information. The DataServer guides present configuration information in traditional client/server terms; when reading this material for implementing WebSpeed, substitute WebSpeed agent for Client.